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Abstract. A variant of Turing machines is introduced where the tape 
is replaced by a single tree which can be manipulated in a style akin to 
purely functional programming. This yields two benefits: first, the extra 
structure on the tape can be leveraged to write explicit constructions of 
machines much more easily than with Turing machines. Second, this new 
kind of machines models finely the asymptotic complexity of functional 
programming languages, and may allow to answer questions such as “is 
this problem inherently slower in functional languages”. 


1 Intro 

This article came to be as I seem to find myself all to often in two kinds of 
discussions: one of them is the functional programmer’s complaint that Turing 
machine make an unpleasant computation model as it is so unstructured that 
writing any explicit Turing machine is a chore usually left to the gods of hand- 
waving. The second one is a common interrogation about some computational 
problem: “is it actually slower by a logarithmic factor to solve with a purely 
functional program, rather than an imperative one”. 

My inner functional programmer’s reflex would be to turn to A-calculus to 
answer such questions. However, there is no denying that it is easier to quantify 
over automata-like machines, such as Turing-machines, for the purpose of proving 
complexity results. With that in mind, I will introduce, in this article, a variant of 
Turing machines, the tree machine, with better structured data which correspond 
faithfully to the cost-model of purely functional programming languages. 

I will not attempt to answer, either positively or negatively, whether con¬ 
crete problems are slower or not in purely functional style; I will however, give 
an explicit description of a machine implementing A-calculus in section [5l to 
demonstrate that it is effectively possible to write non-trivial machines explic¬ 
itly in this model. 
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2 Eilenberg’s machines 


We will work with a generic notion of machines introduced by Eilenberg [5J 
Chapter 10], which can be instantiated to yield finite automata as well as Turing 
machines. The tree machine introduced in Section [3] is yet another instantiation 
of Eilenberg’s machine (in fact we will give several equivalent definitions). 

A type of machine is given by a set X of data and a set <P C V(X x X) 
of instructions. Most of the times the instructions will be partial relations. A 
machine of type ( X , is given by a finite set Q of states, and subsets I and F 
of initial and finite states, as usual for automata. Transitions are labelled with 
relations of <P. A path qo,... ,q n computes the composition of the relations on the 
successive edges. The machine itself compute the union of the relation computed 
by path from an initial state to a final state. 

It does not change the expressiveness to close <P by composition («i -* 2 ), union 
(*1 + * 2 ), identity (lfl and empty relation (0). We shall use this fact implicitly. 

In fact, relations computed by a machine of type (X, <£) are exactly the 
relations in the sub-Kleene algebra of V(X x X) generated by <P: the result for 
finite automata lifts naturally to Eilenberg’s machines. So Eilenberg machines 
are equivalent to regular expressions with alphabet <P. However, if closing <P by 
all the regular expression operations does not change what relation the machines 
compute, it does change the complexity. Since we are concerned with complexity 
properties, we may therefore refer to regular expressions as machines, while we 
will reserve the term instructions to star-free expressions. 

This definition of Eilenberg’s machines is naturally non-deterministic. It 
would be more accurate to work with deterministic machines in the setting of 
this article, but it does not really change anything of substance, and would un¬ 
necessarily clutter the presentation. So the machines throughout this article will 
be non-deterministic, but all of them could be made deterministic, and actually 
should, for practical applications. 


3 Tree machines 

Let us define the set T of (rooted, unlabeled, binary) trees as the set generated 
by the following grammar: 


u,v ::= () | (u,v) 

Such trees will be the data of our tree machines. Take notice of the fact that 
trees do not replace the alphabet of Turing machines but the whole tape: there 
will not be a tape of trees, just one tree. 

1 In Eilenberg’s formulation, a more general kind of relation is considered, in order to 
be able, typically, to count the multiplicity of successful path. In that case, closure 
by 1 ( i.e. adding e-transitions) is not permitted. 



Let us define the following partial functions on T: 


S(x) 

= (' X, x) 


TTl{x) 

= y 

(if 3 z GT . x = ( y,z )) 

K 2 (x) 

= Z 

(if 3 y eT . x = (y,z)) 

(hj) W 

= 0)) 

(if x = ( y , z), for i and j partial functions) 

£ ( X ) 

= 0 


0 (x) 

= 0 

(if x = ()) 


The set of instruction <P is chosen to be the smallest set containing the partial 
functions {< 5 ; 7Ti; tt2', e; (); 1} and closed by (•, •). This set of instructions has been 
chosen to correspond to the presentation of cartesian products and terminal 
elements in categories as adjunctions. 

We call tree machine a machine of type (T, <P). Notice that, contrary to Turing 
machines, tree machines are not parametrised by an alphabet: the tree structure 
offers enough power on its own. 

Tree machines, by virtue of the (•, •) instruction scheme, has an infinite num¬ 
ber of instructions which make it possible to observe the tree and modify it at 
arbitrary depths. However each individual instruction affects trees at a bounded 
depth, which is considered a constant time operation in functional language, 
which is the important property we want to ensure. As we shall see in Sec¬ 
tion 321 this choice of an infinite set of instruction is pure convenience: a finite 
set suffices. 


3.1 A language of guards and actions 


One way to read the instruction in <P, is to think of them as combinators giving 
means to match tree prefixes and rearrange the corresponding subtrees. That 
is, instructions of tree machines perform pattern-matching. We shall give an 
alternative set of instructions for tree machines which is suggestive of the pattern¬ 
matching notation functional programmers all know and love. 

We write 7 =>■ a for a partial function whose domain is denoted by the guard, 
or pattern, 7 and whose functional action is denoted by the action a. Both 7 
and a are trees with variables, with the following restrictions: variables occur at 
most once 7, and all variables of a appear in 7 (variables in 7 bind variables in 
a). We may use 71 => ai | 72 => 02 instead of (71 =>• 07) + (72 =>• a?) when 71 
and 72 denote disjoint domains ( i.e. 71 and 72 are not unifiable). We can also 
use the wildcard pattern “ to represent a variable in 7 which does not bind a 
variable in a. 


For instance, the instructions of can be represented using this notations as 
follows: 

1 = x =>• x 

6 = x => (x,x) 

7Tl = (x, _) =>• x 

*2 = {_,y)=>y 

( i , j ) = (7i, 7 j) =>• («», ) (for i = 7i => 7,- and j = =>• 07) 

£ = ,_=>() 

0 = 0 => 0 


Conversely, the language of guard and action is subsumed by <P, which we 
shall use as a definition rather than giving and independent definition and prove 
it as a theorem (which would be, of course, theoretically possible but not practi¬ 
cally useful). The definition is lexicographically recursive on the subterm ordering 
of 7 then that of a. 


(x => x) 

= 1 



{x => ()) 

= £ 



(0 =* 0) 

= 0 



((71,72) => 0) 

= (( 71 => 0 ) 

,(72 => ()))•£ 


((71,72) => x) 

= ((71 => x ), 

(72 => ())) • 7 Tl 

(when x occurs in 71) 

((71,72) => x) 

= (( 7 i=> 0 ) 

, (72 =>■ x)) • 7r 2 

(when x occurs in 72) 

(7 = 4 > (ai,a 2 )) 

= 5 • ((7 => «i), (7 => a 2 )) 


language of pattern and action 

can be used to 

conveniently defined the 


following examples: 


a = ((x,y) => (y,x)) 

= <*■ ((M) •7T2,(l,£)-7Tl) 

push = ((x,y) ,z) => (x, (y,z)) 

= $■ (((l,e) -7ri,£) -7ri,(5- (((£, 1) •7T2,£) -7ri,((£,£) •£, 1) -7T2)) 


This procedure does not give the smallest possible definition in terms of of a 
and push (or of pretty much anything for that matter). Here are better candidates 
for this particular award: 


a = 6-( 7T2,7Tl) 

push = S ■ (ni ■ ttxjS ■ (n 2 ■ 


In either case, however, it is fair to claim that the language of guard and patterns 
gives a clearer account of the intent and semantics of instructions than the 
more elementary <P. In consequence we will peruse the guard and actions in the 
remainder of the article. 



3.2 Constants 


It will be useful to embed natural numbers in trees. Any embedding will do. We 
choose a binary encoding for the sake of fun and compactness: 


0 

(0 ,n) 
((().()),«) 


0 


2 x n + 1 


2 x n + 2 


A direct consequence of this encoding is that any finite set of symbols can 
be easily represented as particular trees, by mapping them to arbitrary distinct 
natural numbers. We will do so quite liberally. 

3.3 Zipper 

In [ 5 ] Huet presents a purely functional data structure, the zipper to implement 
“pointers” in trees, i.e. a way to walk through a tree from parent to child or back 
in constant time and to replace the pointed subtree also in constant time. 

The zipper can be adapted to the tree machines as a set of instructions. The 
zipper instruction provide us with an ability we have not had so far: modifying 
a subtree at an a priori unbounded depth in a tree. 

The idea is that a zipper is represented as a pair (c, t) of the pointed subtree 
t together with a “reversed tree” c which represents the context and gives enough 
information to rebuild the tree when walking up towards the parent (with the 
instruction up below). Here are the relevant instructions: 


open = x => ((), x) 

left = (x,{y,z))=>{{Q,{x,z)),y) 

right = (x,{y,z))=>{(\,{x,y)),z) 

up = ((0, (x,z)),y) => (x, (y,z)) \ (( 1 , (x, y)), z) => (x, (y,z)) 

exit = (() ,x) => x 


Where open and exit transform a tree into a pointer to its root and back, left 
walks down to the left child (and marks, in the reversed tree, with 0 that it did 
walk down left), right to the right child, and up walks up to the parent, and 
reconstruct the tree according to the mark left by either left or right. For further 
detail, the reader unfamiliar with these concepts is deeply encouraged to read 
Huet’s paper [ 5 ] 

4 Comparisons 

With the basic material now set in place, we can now turn to the use of the tree 
machine as a computational complexity model. It is important to be precise on 
what is meant here: clearly, complexity classes are very robust, and it does not 
matter what computation model is taken to define them; the tree machine is 
no exception. However, for more fine grained accounts of asymptotic complexity, 


the model will matter a lot: in Turing machines already, multiple-tape Turing 
machines can provide a quadratic speedup over single-tape ones. 

It is this sort of complexity that is our concern, and the claim of this arti¬ 
cle is that the tree machine is a good complexity model for purely functional 
computations. 

4.1 Turing machines as tree machines 

It is straightforward to implement Turing machines as tree-machines: fixing a 
coding for the alphabet, we arrange the tree to be a pair (L, R) of lists of symbols. 
The list R = (ao, (ai, represents the part of the tape just under 

and to the right of the head (ao is the symbol under the head). The reversed list 
L = (((... (),...), b2), bi) represents the part of the tape which sits to the left 
of the head. With this representation there is no need for a special symbol to 
stand at empty slots on the tape: instead the symbol under the head is empty 
when R is the empty list (). 

The instruction of Turing machines are implemented as instruction of the 
tree machines (in guard-and-action style): 

— Write symbol a under the head: (L, (_, R )) => (L, (a, R)) \ (x, ()) => (x, (a, ())) 
(the second case extends the tape if we reached the end) 

— Move right: (L, (x, R)) => ((L, x ), R) 

— Move left: ((L, x ), R) =>■ (L, (x, R)) 

— Check that symbol a is under the head: (L, (a, R)) => (L, (a, R)) 

Therefore, a Turing machines is translated to a tree machine with the same state 
and transitions, except the instructions labelling transitions are replaced with 
their respective implementation as tree machine instructions. 

This translation highlights a point which is occasionally overlooked: Turing 
machines are not a very good model of imperative programs. Turing machines 
can be simulated in constant time in a purely functional language, and so can 
multiple-tape Turing machines. To get a better model of imperative programs, 
we shall turn to random-access machines in Section EH 

4.2 A finite type for tree machines 

In order to build the converse translation of tree machines into Turing machines, 
it will be convenient for the set instruction to be presented by a finite set ih To 
obtain this finite presentation we will use the zipper instructions from Section EH 
To be more specific, we will implement the instruction (i,j) £ <P as a (finite) 
sequence of zipper operations which will walk through the tree to apply the 
appropriate actions to the appropriate subtrees. 

Remember that a zipper is a pair (c, t) of a focused subtree t together with a 
reversed tree c representing the necessary context to rebuild the tree. Our goal 
is to lift the instructions of <P so that they apply to the focused subtree instead 
of the root of the complete tree. In other words, we are looking for a [*] = ( 1 , i) 
for each i £<t>. 


This property that [*] = ( 1 , *) acts as a perfectly fine definition for each of 
the generators of <P: 


[1] 

= ( 1 , 1 ) 

[()] 

= (i,0) 

M 

= (M) 

IM 

= (l,7Tl) 


= (1,7T2) 


= (M) 


For the case (i,j) however, in order to avoid introducing infinitely many in¬ 
structions in we need to find an alternative definition in terms of the zipper 
operations. We define recursively as follows: 

[(*,.?)] = left • [i] • up • right • [ 7 ] • up 

It is a straightforward exercise of symbol pushing to verify that indeed, by in¬ 
duction, [(*, j)] = (1, 

Every instruction can be implemented as open • [*] • exit. Therefore we 

can take the set <P as being 

& = {open; left; right; up; exit; (1,1); (1, ()); (1, e ); (1, tti) ; (1, tt 2 ) ; (1, <5)} 

4.3 Tree machines as Turing machines 

Translating tree machines into Turing machines is not as direct as the converse. 
One way to translate trees into word so that it fits a Turing machine tape is to 
use the Polish notations: we take the alphabet to include (p; u} (for pair and 
unit respectively). The tree ((), ((), ())) is then translated to pupuu. 

As always, giving a concrete definition of a Turing machine - or even of a 
translation to Turing machine - is not very easy nor particularly enlightening, 
and, in fact, would lead us way over the page limit. On the other hand, equipped 
with the finite presentation of Section l 4 . 2 l it is quite clear that it can in principle 
be done. 

Let us sketch how such a construction could be achieved. In a first step we 
can ignore the open and exit instruction, and assume we are always working 
on a zipper. The rational is that exit ■ open acts as the identity on a zipper 
which is focused at the root, so we may simply represent non-zipper trees as 
zipper focused at the root and both instructions become the identity. One may 
be tempted to replace calls to exit to test that the context is a u, but this is not 
even necessary as it is an invariant of the translation. 

To represent the zipper (c, t), the most convenient way is to have two tapes, 
one holding c and the other holding t. A third tape will be used to store a counter 
to navigate through Polish-notation trees, and a fourth to store intermediate 
trees which are to be moved or copied. 

The instructions of tree machines are not translated as constant time instruc¬ 
tions. However, they are all in a polynomial P (which depends on the details of 


the translation, but is at least of degree 1 ) of the current size of the tape. Hence, 
if the complexity of a tree machine is 0 (/(n)), then the corresponding Turing 
machine has complexity 0 (P(f(n )) x f(n)), which is in the same complexity 
class. 

Therefore, tree machines and Turing machines have the same complexity 
classes. However, the translation from tree machines to Turing machines is non¬ 
trivial both in term of slowdowns of the translated machine and complexity of 
the translation itself. It would be quite hard to get an explicit description of 
the translation. On the other hand the translation of Turing machines into tree 
machines is quite direct. Tree machines fare pretty well on that front. 


4.4 Tree machines and random-access machines 

Random-access machines - which happen to be yet another instance of Eilenberg 
machine - support more natural translations of tree machines: the encoding of 
algebraic data types of functional programming languages. In such a translation, 
a tree is encoded as an address, at this address there is 0 if the tree is empty, 
and 1 if the tree is a pair. In the latter case, the two following addresses contain 
the addresses of the two subtrees. 

Unfortunately, this translation would not fit these pages either, as it has 
to solve the problem of memory allocation and garbage collection in order to 
preserve the space complexity of tree machines. Garbage collection can be done 
achieved via reference counting [B] since the tree cannot have cycles, but it still 
would not make a program under a page long (or anything near it). 

Nevertheless, this translation is quite concrete and serves as a good test for 
the tree machine. Tree machines, indeed, can implemented in the traditional com¬ 
plexity model of practical computer and, assuming garbage collection away, this 
implementation preserves the complexity of machines. Assuming that garbage 
collection is constant time may seem unreasonable, but it is in fact the way func¬ 
tional programmers think about their programs: as having negligible overhead 
due to garbage collection. 

This translation also serves to remark a limitation of the tree machine for 
space efficiency. Indeed trees can have various representations in a random-access 
machine with more or less sharing between subtrees. In the worst case, a max¬ 
imally shared subtree is exponentially smaller than its sharing-free equivalent. 
Therefore, in an accurate cost model for tree-machine space consumption, the 
space occupied by a tree cannot be read on the tree itself: it depends on the 
history of how the tree was built. There is no particular problem in defining 
such a dynamic space-cost semantics though, see ( 3 j for a much more ambitious 
case. It also means that the translation to Turing machines in Section FOl is not 
accurate as far as space complexity is concerned. 

Conversely, it is not difficult to implement a random-access machine as a tree 
machine. Random-access machines are composed of arithmetic operations and 
an addressed memory. Arithmetic is straightforward, and addressed memory can 
be stored in a tree (most likely a trie such as in [ 7 J Chapter 10 ]). 


Random-access machines typically assume constant time arithmetic opera¬ 
tions and memory access. The translation of random-access machines into tree 
machines preserves neither. For the case of constant-time arithmetic, the as¬ 
sumption is not realistic for big numbers, it is actually meant to model the fact 
that no big numbers will appear and that bounded arithmetic is sufficient for 
the modelled algorithms. To make such an hypothesis in tree machines, they 
would need to be outfitted with a primitive notion of integers like random-access 
machines. 

Constant-time memory access is more subtle: it is a reasonable assumption for 
a vast majority of programs, yet, a more accurate model may use logarithmic¬ 
time memory access [ 2 ]. Logarithmic-time memory access is precisely what is 
provided by the tree machine, so it might look as though the superiority of the 
random-access machine were illusory. It is not, however, as when a model with 
logarithmic-time memory access apply, it will not be a priori reasonable to see 
the instructions of the tree machines as running in constant time. 

5 Encoding A-calculus 

To conclude, I want to present, with few words, an encoding of A-calculus in tree 
machines to demonstrate that it is really practical to make explicit definitions 
of non-trivial machines. 

We shall use the simple explicit substitution calculus called Ar>-calculus [6]. 
It uses de Bruijn indices and has three kinds of substitutions: [u] for a term v, 
[jj (read shift) and [fi s] (read lift s) for a substitution s. 


(A u)v 


u\v\ 

(A u)[s] 


A(u[fr s]) 

(uv) [s] 


(“[*])(«[*]) 

OH 


V 

(n + l)H 


n + 1 

0 [lt s] 


0 

{n+ i)[fr s] 


n[s][t] 

«[t] 


n + 1 


Let us suppose fixed an encoding for the symbols that we will use in the 
encoding of terms: {A; app; succ; nought; subst; term; lift; shift; ok}. The terms Xu 
and uv are represented, respectively (A, u ) and (app, (u, v)). The de Bruijn index 
2 is represented as (succ, (succ, nought)). 

We will use the non-determinism of tree machines to represent the non¬ 
determinism of / 3 -reduction, which is achieved navigating non-deterministically 
in A-terms with zipper-like instructions. 


open 

= u=>{Q,u) 




down> 

= H, (A,u)) =>■ ((c, A) ,u) 



down CT 

= (c, (subst, (u,sj)) =k (0 

c, (subst, 

s)),u) 

left 

= (c, (app, (u, 

«))) =► (H 

(app, (0, 

v))),u) 

right 

= H, (app, (u, 

«))) =*> (H 

(app, (1, 

u))),v) 


u Pa 

((c, A ),«)=> (c, (A,u)) 

u Pa 

((c, (subst, s )), u) => (c, (subst, (u , s))) 

u Papp 0 ^ 

((c, (app, (0, v ))), u) => (c, (app, (u, v))) 

u Pappi ^ 

((c, (app, (1, it))), v) =h (c, (app, (u, v))) 

up = 

u Pa 1 up CT | up apPo | up appi 

exit = 

((),«) =>« 

move = 

dowriv + dowrio- + left + right + up 

zip 

up* • exit 

The reduction rules are given in a context independent manner: 

P 

= (app, ((A, u ), v)) =>■ (subst, ( u , (term, v))) 

Act 

= (subst, ((A, u ), s)) =>• (A, (subst, (u, (lift, s)))) 

apP CT 

= (subst, ((app, (u, v )), s)) => (app, ((subst, (u, s)) , (subst, ( v , s)))) 

nOU g ht term 

= (subst, (nought, (term, v))) => v 

SUCCterm 

= (subst, ((succ, n) , (term, ))) =>■ succ(n) 

nought lift 

= (subst, (nought, (lift, ))) => nought 

SUCClift 

= (subst, ((succ, n) , (lift, s))) => (subst, ((subst, (x, s)) , shift)) 

nought shift 

= (subst, (nought, shift)) =£- (succ, nought) 

SUCCshift 

= (subst, ((succ, n) , shift)) => (succ, (succ, n)) 

var shi ft 

= nouhgt shift | succ s hift 

a 

= A ct app CT nought term succ te r m nought lift succnft var sh ift 

A step of /3-reduction is represented as one /3 rule followed by eagerly applying 
a rules. To ensure that explicit substitutions have been eliminated, substitution- 
free terms are marked with ok. 

nought ok 

= nought =>■ (ok, nought) 

succ ok 

= (succ, n) =$■ (ok, (succ, n)) 

Aok 

= (A, (ok,w)) =h (ok, (X,u)) 

a PPok 

= (app, ((ok, u) , (ok, v))) => (ok, (app, (u, v))) 

rule Q k 

= nought ok + succ ok + A ok + app ok 

check ok 

s 

It 

's' 

o 

II 

A step of /3-reduction is encoded as the following machinal: 

all a = 

(move* • (1, a))* 

z 'Pok = 

(move* • (1, rule ok ))* • exit • check ok 

step = 

open • move* • (1, /3 ■ open • all CT • zip ok ) • zip 


6 Conclusion 

The tree machine is designed to stand as a standard model of complexity for 
purely functional algorithms, much like the random-access machine is for imper¬ 
ative algorithms. At the cost of not being quite as minimalist as Turing machines, 

2 Notations are abused a little in this example, as (•, •) is used with relations which 
are not instructions from the type 4 >. It can be made formal using Section 14. 21 



tree machines are quite expressive and make it reasonably easy to write explicit 
machines to implement desired behaviours. 

In fact, if in this article I have given direct descriptions of machines, a tech¬ 
nique, favoured by Danvy, allows to compile programs written in a very small 
purely functional idealised Scheme language, with full recursion and higher order, 
into a tree machine. This is achieved by apply sequentially to the program the 
following transformations: defunctionalisation, continuation-passing style trans¬ 
formation, and defunctionalisation again [T]. This sequence of transformation 
yields a mutually recursive first-order program where all calls (in particular re¬ 
cursive calls) are tail, while preserving the structure of the program. At this 
point we are one tiny step shy of having a tree machine: function environments 
must be reified as data and variables as accessors in this data. Then, using the 
guard-and-action presentation of tree machines, we can build a machine with 
just one state per function in the transformed program (the functions of the 
original program plus one or two administrative functions). Yielding another, 
more indirect, way to produce explicit tree machines. 
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